Software has become increasingly complex as processor capability, memory density, and users' expectations have grown. As a result, methods and tools for managing software development projects have become increasingly important, including methods for determining software complexity to be used in estimating, for example, how many defects are expected to occur in a software component, how many hours of development time are expected to be needed for the completion of a project, and so forth.
Today, such estimates are normally based on counts of lines of code, together with some simple rules for determining what, roughly, constitutes a line of code. For example, a certain development time and a specified number of defects may be expected per thousand lines of code. This method may be called generically the KLOC method.
The KLOC method, while certainly useful, has significant drawbacks. These drawbacks are a product of the highly variable nature of software components. Some components are rich in unique code, whereas other components include substantial repetitions, spaces, blank lines, comments, and so forth. Thus, when two software components are compared using the KLOC method, where one component is rich in unique code while the other is highly repetitive and full of comments, the resulting estimates will be inconsistent. The two estimates might be numerically the same, for example, whereas in reality the software that is rich in unique code is rationally expected to be more difficult to develop, and therefore to require more development time and be more susceptible to defects. Furthermore, the KLOC method is strongly tied to the properties of the particular programming language in question, as some languages are inherently more dense than others.
Thus, there is a need for a language-independent way to determine software complexity consistently, so that software project estimates such as expected development time, expected numbers of defects, and so forth, may be determined more accurately than is possible today.